The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to mechanisms for handling DNS (domain name system) requests and responses within a data network having IPv4 only devices, IPv6 only devices, and dual-stack devices.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow IP address to be duplicated across local networks.
Another solution to the lack of available IP addresses is to redesign the address format to allow for more possible IP addresses. The recent introduction of IPv6 provides 128 bits for the IP address, as compared with IPv4 which provides 32 bits for the IP address. However, until all network devices and computers are converted to IPv6, it is still necessary to allow an existing IPv4 device to communicate with an IPv6 device. One popular method that allows IPv4 to IPv6 communication is referred to as protocol translation (NAT-PT). The IP addresses are converted by NAT-PT from one protocol to another protocol (e.g., IPv4 to IPv6 or vice versa) or from an external protocol to an internal protocol (e.g., IPv4 to IPv4). In addition to the IP addresses, the NAT-PT also converts any relevant IPv4 or IPv6 information during a protocol translation.
A packet may also contain address(es) embedded in the payload that require translation. Particular applications may embed address(es) in the payload for various application specific purposes. The current approach for supporting applications which embed IP addresses in the payload (e.g., DNS (domain name system), FTP (file transfer protocol), H.225/H.245) in a NAT environment is to add application-specific knowledge within the NAT device itself. This approach is described in detail in the Internet Engineering Task Force's Request for Comments document RFC 2663, entitled IP “Network Address Translator (NAT) Terminology and Considerations” by P. Srisuresh and M. Holdrege of Lucent Technologies (August 1999), which document is incorporated herein by reference in its entirety.
Name to address mappings are maintained by each DNS server. For instance, IP version 4 name to address mappings are held in “A” records, while IP version 6 name to address mappings are held in “AAAA” records. A particular domain name may have an IP version 4 address and/or an IP version 6 address mapping. An IP version 4 address includes 32 bits, while an IP version 6 address includes 128 bits.
FIG. 1 is a diagrammatic illustration of a conventional network 100. As shown, the network 100 includes a WAN (wide area network) network 110 and a LAN (local area network) network 114. The WAN 110 includes a DNS server 102 that is both IPv4-DNS-server and IPv6-DNS-server, a dual-stack (both IPv4 and IPv6 stacks) device 104, an IPv4-only device 106, and an IPv6-only device 108. The LAN network 114 consists of an IPv4-only device 118 and an IPv6-only device 116.
In order for these devices to use DNS names to communicate with each other, a router or a gateway 112, running NATPT (network address translation-port translation) and DNSALG (domain name system application level gateway), is needed in the path from one device to the other. The NATPT module in this router/gateway translates IPv4 packets to IPv6 and IPv6 packets to IPv4. The DNSALG module in the router/gateway snoops the DNS packet payloads, and translates IPv4 DNS query/response/inverse-query/inverse-response packets to IPv6 and translates IPv6 DNS query/response/inverse-query/inverse-response packets to IPv4.
The design of NATPT and DNSALG modules can be based on RFC 2766, “Network Address Translation-Protocol Translation (NAT-PT),” by Tsirtsis, G. and Srisuresh, P., February 2000, which is incorporated by reference in its entirety. Though RFC-2766's design of the NATPT module is complete, the DNSALG module is incomplete and does not work satisfactorily for the existing real-world network topologies.
RFC-2766's design of DNSALG addresses the network topologies which are IPv4-only and IPv6-only. This RFC does not have mechanisms for handling the situation where both IPv4-only devices and IPv6-only devices coexist in the same network. For example, consider the topology shown in FIG. 1, where both the networks LAN and WAN have both IPv4-only and IPv6-only devices. In this case, a network interface on the router/gateway 112 can receive both IPv4 and IPv6 packets. This situation is not handled by RFC-2766.
Additionally, if the router/gateway 112 is also used as a DNS server (IPv4 or IPv6), then the DNS queries have to be forwarded to this DNS server too, and the responses from this DNS server are not translated. For example, if the router/gateway 112 of FIG. 1 has both IPv4 and IPv6 DNS servers (actually the same DNS server can be configured to be both IPv4 and IPv6 servers), referred to as the IPv4+IPv6-DNS-server or IDS (Internal IPv4+IPv6 DNS server). The DNSALG does not forward translated queries to IDS and read the responses from IDS and translate the responses. In other words, this situation is not handled by RFC-2766.
According to RFC-2766, when an IPv4-only device wants to resolve the name of any device and if the query reaches DNSALG 112, the original IPv4 query is dropped. This is not a very efficient technique in the case where a dual-stack device exists in the network. For example, in FIG. 1, when IPv4 only device 118 of LAN 114 needs to resolve the name of dual stack device 104 of WAN 110, the IPv4 query reaches the DNSALG 112. The DNSALG 112 translates this to IPv6-DNS-query and drops the original IPv4-DNS-query. The DNSALG 112 then receives the IPv6-DNS-response which would contain the IPv6 address of dual stack device 104 of WAN 110. This IPv6 address will then be used to communicate between IPv4 only device 118 of LAN 114 and dual stack device 104 of WAN 110. Though the communication is possible through IPv4-IPv6 translations, the same communication could have been possible using the IPv4 address of dual stack device 104 of WAN 110. This would have eliminated the need and the time required for translation of every packet that could have just been fine without translation, had it used the IPv4 address of dual stack device 104 of WAN 110. This inefficiency becomes a potential problem when the number of connections is large, which creates bottlenecks for other packets and introduces unneeded delays in packet processing at the router/gateway.
A similar problem arises when a situation is considered where an IPv6-only device needs to communicate with a dual-stack device. For example, in FIG. 1, suppose the IPv6 only device 116 of LAN 114 needs to resolve the name of dual stack device 104 of WAN 110. The IPv6 only device 116 of LAN 114 ends up using the IPv4 address of dual stack device 104 of WAN 110, instead of the IPv6 address of the dual stack device 104 of WAN 110. This adds to the inefficiency in the design of DNSALG 112, thus increasing the packet processing times of other packets in the router/gateway.
Current DNS resolvers (in both IPv4 DNS clients and IPv6 DNS clients) work in the following way: A resolver sends a DNS-query on a port and wait for a response on the same port. When the resolver receives a response, it closes the port and does not listen to any further responses, meaning, the resolver listens to only the first response packet. If this first response packet has some answer records, then the resolver opens a data connection to the IP address specified in the answer records. But if this first response packet does not have any answer records, the resolver does not open any data connection. In this situation, where the first response packet has no answer records, even though a response packet with some answer records reaches the DNS-client after some time, the DNS-client will not be able to open a session. This behavior of DNS-clients is a potential problem when they interoperate with RFC-2766's DNSALG. According to RFC-2766, when an IPv6-only device wants to resolve the name of any device, the DNSALG should forward the original IPv6-DNS-query to IPv6-DNS-server and a translated-IPv4-DNS-query to the IPv4-DNS-server. If in FIG. 1, the IPv6 only device 116 of LAN 114 wants to resolve the name of any other device, then the DNSALG in router/gateway 112 forwards two queries to the DNS-server 102, one the original IPv6-DNS-query and second the translated-IPv4-DNS-query. This is a potential problem in two situations.
In a first case, the IPv6 only device 116 of LAN 114 wants to resolve the name of an IPv4-only device, like the IPv4 only device 106 of WAN 110. The DNSALG 112 forwards both IPv6-AAAA query and the IPv4-A query to the DNS-server(s) 102. Since the IPv4 only device 106 of WAN 110 is an IPv4-only-device, the IPv4-DNS-response would have the actual IPv4 address of the IPv4 only device 106 of WAN 110, and the IPv6-DNS-response would have zero answer records. If this IPv6-DNS-response, which has zero answer records, reaches the DNSALG 112 first, then this zero record response is forwarded to IPv6 only device 116 of LAN 114. The resolver-client in IPv6 only device 116 of LAN 114 realizes that there are no answer records in the response and thus does not try to establish a connection with the IPv4 only device 106 of WAN 110. After some time, the translated IPv4-DNS-response reaches IPv6 only device 116 of LAN 114, but this response is ignored by the resolver-client. This defeats the whole purpose of DNSALG to resolve names. Due to a difference in the timings at which the responses arrived at DNSALG 112, the establishment of the IPv6-to-IPv4 connection was not possible.
In a second situation, the IPv6 only device 116 of LAN 114 needs to resolve the name of an IPv6-only device, like the IPv6 only device 108 of WAN 110. In a specific situation, the translated IPv4-response with NULL answer records reaches the DNSALG 112 first. The DNSALG 112 translates this response to IPv6 and forwards it to IPv6 only device 116 of LAN 114. The actual IPv6 response with a valid answer record reaches the IPv6 only device 116 of LAN 114 after some time. This is ignored by the resolver client in IPv6 only device 116 of LAN 114. This handling specified by RFC 2766 again defeats the whole purpose of DNSALG.
In view of the above, there is a need for improved mechanisms for more efficiently and reliably processing DNS queries and responses.